Review

Issues

1. Bug: TLS cert path missing the endpoint subdirectory

Docker stores context TLS files at contexts/tls/<hash>/docker/{ca,cert,key}.pem (where docker is the endpoint name), not directly at contexts/tls/<hash>/. The Docker CLI source (store.go ResetEndpointTLSMaterial) writes to:

filepath.Join(s.tls, contextDirOf(name), endpointName, fileName)

And docker context inspect's Storage.TLSPath returns the context-level directory (contexts/tls/<hash>/), not the endpoint-level one.

The PR reads from:

os.ReadFile(filepath.Join(tlsPath, "ca.pem"))   // contexts/tls/<hash>/ca.pem

But should read from:

os.ReadFile(filepath.Join(tlsPath, "docker", "ca.pem"))   // contexts/tls/<hash>/docker/ca.pem

This applies to both the Storage.TLSPath path and the fallback calculated path. The tests pass because they create certs at the wrong level to match the code, not where Docker actually stores them. On a real Docker installation with TLS-enabled contexts, the certs would not be found.

2. Mock daemon doesn't serve the Info endpoint

startMockDaemon returns "OK" (text/plain) for all requests. The TLS tests call dockerClient.Info() and assert nfo.Info.ID == "mock-daemon":

nfo, err := dockerClient.Info(ctx, client.InfoOptions{})
if nfo.Info.ID != "mock-daemon" {
    t.Errorf(...)
}

The Docker client should fail to JSON-decode "OK" into a system.Info struct, causing Fatalf on the error check. If it somehow succeeds, the ID would be "", not "mock-daemon", so the Errorf would fire. Either the mock needs to serve proper JSON for /info, or the Info() assertions should be removed.

3. Context TLS tests don't isolate from DOCKER_TLS_VERIFY

TestNewClient_DockerContextTLS and the fallback variant set DOCKER_HOST="" and DOCKER_CONFIG but don't unset DOCKER_TLS_VERIFY. If the test environment has DOCKER_TLS_VERIFY set, newHttpClient() takes the env-var code path instead of the context path, and the test doesn't exercise what it claims. These tests should explicitly unset DOCKER_TLS_VERIFY and DOCKER_CERT_PATH.

4. Test meta.json includes Storage field that Docker doesn't persist

createDockerContextConfigWithTLS writes a Storage block into meta.json. Docker CLI doesn't store Storage in meta.json -- it computes it at runtime from the store directory structure. The real docker context inspect will ignore the Storage in meta.json and compute its own value. This means the test's TLSPath value may or may not match what docker context inspect actually returns, making the test fragile.

Minor / Style

• Code duplication -- newHttpClient (env var path) and newHttpClientFromContext duplicate the dialer + transport + http.Client construction. A small shared helper for the bottom half would reduce this.
• Silent cert read failures -- getDockerContextConfig silently returns empty cert slices when os.ReadFile fails for individual cert files. A debug/trace log would help users troubleshoot TLS issues (the PR does log X509KeyPair failures, which is good, but not file-read failures).

Positive

• Caching contextConfig to avoid calling docker context inspect twice is a good improvement.
• Proper precedence: env vars override context config.
• Clean separation of newHttpClientFromContext from the env-var path.
• Good test structure with TLS mock daemon (CA, server cert, client cert).
• Removing the exported GetDockerContextHostFunc mock variable in favor of DOCKER_CONFIG-based test isolation is the right approach.
• The fallback path calculation for <IN MEMORY> TLS paths is a nice touch.

Review: PR #3728 — feat: add TLS certificate support for Docker contexts

Summary

This PR extends the Docker context detection (from #3684) to also load TLS certificates stored in Docker contexts. It renames getDockerContextHost() to getDockerContextConfig(), returning a dockerContextConfig struct that carries both the host and TLS cert/key/CA bytes. The newHttpClient() function is updated to accept this config and fall back to context-based TLS when env vars aren't set.

Issues

1. TLS cert path lookup assumes flat directory — Docker uses a subdirectory per endpoint

At docker_client.go:450-453, the fallback path is computed as:

hash := sha256.Sum256([]byte(contexts[0].Name))
tlsPath = filepath.Join(dockerConfigDir, "contexts", "tls", fmt.Sprintf("%x", hash))

But Docker actually stores TLS files under contexts/tls/<hash>/docker/ (one subdirectory per endpoint name). The certs won't be found at the computed path on a real Docker installation. The tests pass only because they write certs directly into contexts/tls/<hash>/ — mimicking the bug rather than real Docker layout.

2. contextConfig is passed to newHttpClient even when DOCKER_HOST is set via env

At line 184, newHttpClient(contextConfig) is called whenever the scheme is TCP. But contextConfig is only populated when the default socket doesn't exist (the os.IsNotExist branch). If DOCKER_HOST is set as an env var (line 94), contextConfig will be nil, so this works correctly — but only by coincidence. The code would be clearer if the call was newHttpClient(nil) when DOCKER_HOST came from the environment, or if the logic was restructured.

3. Missing DOCKER_TLS_VERIFY env var cleanup in context TLS tests

TestNewClient_DockerContextTLS and TestNewClient_DockerContextTLS_FallbackPath set DOCKER_HOST and DOCKER_CONFIG via t.Setenv, but they don't explicitly clear DOCKER_TLS_VERIFY. If DOCKER_TLS_VERIFY happens to be set in the test runner's environment, the env-var path in newHttpClient would take precedence over context TLS, and the test would pass for the wrong reason. Adding t.Setenv("DOCKER_TLS_VERIFY", "") would make the tests more robust.

4. os.Getenv("HOME") won't work on all platforms

At docker_client.go:446:

dockerConfigDir = filepath.Join(os.Getenv("HOME"), ".docker")

On Windows, HOME is typically not set (USERPROFILE is used instead). The test already skips Windows, but the production code doesn't. Consider using os.UserHomeDir() instead, which is cross-platform.

5. CodeQL warning about InsecureSkipVerify

The two CodeQL alerts on InsecureSkipVerify are false positives in the context of this PR — the InsecureSkipVerify in the env-var path was already present before this PR, and in the context path it's only set when SkipTLSVerify is explicitly configured. However, a //nolint or #nosec annotation with a justification comment would silence the scanner and document the intent.

Minor Nits

• The "crypto/sha256" and "fmt" imports were added to the production code solely for the TLS path fallback logic. If issue #1 above is fixed to read the TLSPath from docker context inspect output correctly, the sha256 import may become unnecessary.
• The comment at line 399 (// Note: DOCKER_CONFIG is automatically inherited from parent environment) is obvious and could be removed.
• newHttpClientFromContext logs to stderr on cert parse failure (fmt.Fprintf(os.Stderr, ...)). The rest of the codebase doesn't use this pattern — consider using a proper logger or just returning nil.

What's Good

• Clean precedence model: env vars override context config.
• The dockerContextConfig struct is a reasonable abstraction for carrying context state.
• The test coverage is thorough: context TLS, fallback path, and env-var backward compatibility are all covered with real mTLS connections to mock daemons.
• The caching of contextConfig to avoid calling docker context inspect twice is a good optimization.

Verdict

The core idea is sound, but the TLS path lookup (issue #1) appears to be incorrect for real Docker installations, which would make this feature silently not work outside of the tests. That should be verified and fixed before merging.

Review — Round 2

The latest fixup commit (d217408) claims to address all 5 issues from the previous review but issue #1 (TLS cert path) is only partially fixed, and issue #3 (DOCKER_TLS_VERIFY cleanup) was not actually applied despite the commit message claiming it was.

1. TLS cert path still wrong for the primary (non-fallback) path — CRITICAL

The fallback path at docker_client.go:466 was correctly fixed to include /docker/:

tlsPath = filepath.Join(dockerConfigDir, "contexts", "tls", fmt.Sprintf("%x", hash), "docker")

But when Storage.TLSPath is a valid absolute path (the primary path), the code at lines 470-482 reads directly from it:

os.ReadFile(filepath.Join(tlsPath, "ca.pem"))  // reads from contexts/tls/<hash>/ca.pem

docker context inspect returns the context-level directory for Storage.TLSPath (i.e. contexts/tls/<hash>/). Docker stores the actual cert files one level deeper at contexts/tls/<hash>/docker/{ca,cert,key}.pem (where docker is the endpoint name).

Since docker context inspect always computes a valid absolute TLSPath at runtime (it doesn't read Storage from meta.json — it synthesizes it from the store directory structure), the fallback branch is effectively dead code in practice. The primary (broken) path is always taken.

The fix needs to append "docker" in the primary path as well:

os.ReadFile(filepath.Join(tlsPath, "docker", "ca.pem"))

The tests pass because they create certs at contexts/tls/<hash>/ (matching the bug, not real Docker layout). They should create certs at contexts/tls/<hash>/docker/ instead.

2. Fallback test doesn't actually test the fallback path — MEDIUM

TestNewClient_DockerContextTLS_FallbackPath writes "<IN MEMORY>" into meta.json's Storage.TLSPath field. However, docker context inspect computes Storage at runtime from the store directory structure — it doesn't read it from meta.json. So docker context inspect will return a valid absolute path regardless, and the fallback logic is never exercised.

Additionally, the test writes certs to contexts/tls/<hash>/ (without /docker/), but the fallback code now computes the path as contexts/tls/<hash>/docker/. If the fallback were actually exercised, the certs wouldn't be found and the test would fail.

3. DOCKER_TLS_VERIFY isolation still missing — MEDIUM

The commit message for d217408 claims t.Setenv("DOCKER_TLS_VERIFY", "") was added to both TLS tests, but it's not in the code.

Moreover, t.Setenv("DOCKER_TLS_VERIFY", "") would be the wrong fix — os.LookupEnv treats an empty-but-set variable as "set", so tlsVerifyChanged would be true and the env var code path would execute instead of the context path. The tests need to properly unset the variable:

os.Unsetenv("DOCKER_TLS_VERIFY")
os.Unsetenv("DOCKER_CERT_PATH")

4. fmt.Fprintf(os.Stderr, ...) for warnings — LOW

At docker_client.go:337, the warning about failed TLS client cert loading uses raw stderr writes. The rest of the codebase doesn't use this pattern.

5. Code duplication — LOW

The dialer + transport + http.Client construction is duplicated between the env var path in newHttpClient and newHttpClientFromContext. A small shared builder would reduce this.

What's good

• Caching contextConfig to avoid double docker context inspect calls is a good improvement.
• The env var > context precedence model is clean.
• Removing the exported GetDockerContextHostFunc mock variable is the right call.
• os.UserHomeDir() fix (issue #4 from previous review) was properly applied.
• The backward-compatibility test (TestNewClient_TLS_EnvVars) is solid.

Verdict

Issue #1 is the blocker — the feature won't work on real Docker installations because the primary TLS path is always used and it's missing the /docker/ endpoint subdirectory. The tests need to be restructured to match real Docker directory layout to catch this.